Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Secure by Design: Why Security Shouldn't Be an Afterthought in Software Development

Rianat Abbas — Sat, 04 Jan 2025 01:30:00 GMT

Building software products that solve actual customer concerns and generate business success is not an easy fit. Product executives battle strong competition, tight timelines, and high expectations, all while seeking to offer value. While success gives the opportunity to showcase approaches and frameworks, the reality is that building excellent products is rarely straightforward. As artificial intelligence continues to improve and incorporate into our daily lives, the sophistication of cyberattacks is also increasing. Recent occurrences such as the ChatGPT software leak and the Activision Blizzard data breach emphasize the critical need for stronger cybersecurity safeguards to be put in at every level of application and software development. Every product or technological advancement must have security built into its very foundation from the very beginning of its conception.
However, it is clear that implementing a reactive approach to security within software development is insufficient, as 77% of organizations reported an increase in cyberattacks in 2021, and 80% of successful breaches involved new or unknown zero-day attacks (often resulting from the exploitation of undisclosed vulnerabilities).
The growing number of security events emphasizes how crucial it is to give security factors top priority throughout the design and development of new products rather than considering them as a secondary issue. Many flaws and weaknesses that attackers actively take advantage of can be avoided by incorporating security into systems from the very beginning.

Recognizing the need for product security today
A product's security has a direct impact on its market performance in a time when customer trust is crucial. Consumers are increasingly aware of data privacy and the security of the products they use. This heightened awareness, combined with the rapid incorporation of Gen AI in products, requires a robust approach to managing product security risks. These risks can lead to compliance failures, operational disruptions, data breaches, and more.

What Is Secure By Design?
"Secure by Design" is a methodology that incorporates security into the foundation of product and software development from the start. This process ensures that strong, multi-layered security mechanisms are implemented at all stages of development, from original planning to deployment. Secure coding techniques are routinely followed, and rigorous testing is carried out to find and address vulnerabilities before products are released.
Organizations that integrate security early can guard against insider attacks, limit risks along the cyberattack kill chain, and avoid the reactive cycle of correcting vulnerabilities after launch. This strategy makes security an integral and ongoing part of the development process, rather than an afterthought introduced later in the cycle.

The Cost of Ignoring Security Early
Taking a reactive approach to security, which involves remediating vulnerabilities after a product has been built, has long been normal practice. However, this thinking frequently results in costly repercussions. Ignoring security during the early stages of development permits design flaws and security debts to build up, transforming easy remedies into complex engineering problems. Furthermore, post-implementation security testing may miss logic mistakes or workflow issues that were present during initial development, giving a misleading sense of security. By the time vulnerabilities are recognized, the underlying problems may be too deeply ingrained to adequately address.
The impact of security breaches on enterprises can be disastrous, which most times can lead to the following:

Financial losses: Cyberattacks result in stolen data, fraud, and operational disruption, which can cost corporations billions.
Reputational damage: For every breach that happened, it undermined customer trust, affecting brand loyalty and income.
Legal repercussions: Regulatory fines, lawsuits, and compliance violations can also add to the financial and reputational burden.
Operational disruptions: Security events affect workflows, lowering productivity and risking business continuity.

Integrating Security Into the Development Lifecycle
Products are designed to be resistant to emerging risks from the outset by proactively incorporating security into the development process. Throughout the whole development process, security is prioritized, which lowers vulnerabilities, increases product resilience, and builds customer trust. To properly integrate security into product development, the following steps must be taken:

Conduct regular security audits. - Regular audits of the code and infrastructure help identify and address vulnerabilities before they become significant risks. These audits prevent serious breaches by addressing issues early and ensuring that systems are secure against potential attackers.
Implement Secure Coding Techniques - Using secure coding methods such as data validation, encryption, and input sanitization reduces the likelihood of vulnerabilities. By taking these safeguards during development, teams may ensure the integrity and security of their products.
Use Frameworks for Secure Development - Using safe frameworks streamlines the integration of integrated security features, protecting products from common threats. This approach integrates security as a fundamental part of the development process and boosts productivity.
Train Teams in Security Best Practices - Teaching development teams about current security threats and trends fosters a culture of security-first thinking. Empowered teams reduce risks and enhance product security by making well-informed decisions that prioritize protection at every turn.
Stay Up to Date on Security Trends - Teams can proactively mitigate risks by monitoring evolving threats and vulnerabilities, safeguarding products from sophisticated attacks, and assisting companies in adapting to new challenges.

Security Considerations By Project Stage
Integrating security efforts with existing development workflows requires forethought at each product delivery phase, including:

Requirements Gathering: Perform asset identification and risk analysis and establish security goals. Build abuse stories showing attack vectors and threat scenarios.
Architecture & Design: Select inherently secure frameworks and components. Apply principles like least privilege and fail-safe defaults when detailing technical design.
Implementation & Testing: Adopt secure coding best practices. Perform static and dynamic analysis security testing to catch defects early.
Post-Launch: Run penetration tests mimicking real-world attacks. Set up monitoring for anomalous access patterns or errors indicating compromise. Establish secure update processes.

By mapping security concepts to existing development lifecycles, product teams more easily reason about where best to invest efforts for maximizing risk reduction at each stage.

Implementing Secure Software Development Lifecycle (SDLC) Practices
Secure SDLC is a methodology that integrates security best practices into every stage of the development process. Here’s how:
DevSecOps: This collaborative approach fosters seamless integration of security considerations throughout the development, security, and operations pipelines. By breaking down silos between development, security, and operations teams, DevSecOps enables a more holistic approach to product security.
Integrating Security in Agile Development: Agile development’s iterative nature necessitates embedding security testing within each sprint, ensuring continuous security evaluation. This ongoing focus on security throughout the development process helps to identify and fix vulnerabilities early, before they become major problems.
Security Checkpoints in Product Development: Implementing security checkpoints at critical milestones throughout the development lifecycle guarantees ongoing evaluation and mitigation of vulnerabilities. These checkpoints can include code reviews, penetration testing, and vulnerability assessments, ensuring that security remains a top priority throughout the development process.
By adopting these practices, businesses can significantly reduce the risk of security breaches and build products with inherent resilience.

Treating Security as a Core Requirement in Planning
Product managers play a crucial role in ensuring that development teams prioritize high-value work via a methodical planning process. While engineering leaders and product designers are typically engaged in feature planning discussions, security specialists are often excluded since security is perceived as a non-functional necessity that will be addressed later. This approach maintains the notion that security can be "layered on" after development, which raises risks and creates vulnerabilities. To address product risks and vulnerabilities in software development, product managers must prioritize security in the software planning process. This means that when discussing new features and functionalities, security experts should be involved from the start. Rather than adding security as an afterthought, it should be integrated and planned for from the outset. Product managers, like software engineers, data analysts, and user experience professionals, must master the fundamentals of security. Understanding the vocabulary and cooperating with security teams means that secure practices are built in from the start of product development, even if they are not supposed to be security experts.

Conclusion
Security is a foundational element of product development, not an afterthought or optional feature. Product managers and the entire software development team must ensure that security requirements are prioritized from the start, integrating them seamlessly alongside functionality and user experience. Security teams play a vital role in enabling this by offering best practices and actionable recommendations.
In an era of increasing cyber threats, treating security as intrinsic to design—rather than a premium add-on—builds trust and safeguards customers. By adopting proactive measures like early security analysis, secure design principles, and continuous testing, organizations can create resilient products that protect both users and their reputation in the long run.

Requirements in Context Part 1 - Just Know It!

Dan Tasker — Mon, 22 Oct 2018 20:23:00 GMT

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.”A perfect illustration of this is the classic IT cartoon “The Swings”:

What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice. It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system’, from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”

Next article: Requirements In Context Part 2 - The Functional View From 10,000 Feet

Minimum Viable Product – A concept misunderstood

Surbhi Mahnot — Mon, 23 Nov 2015 05:21:00 GMT

What is MVP?

Minimum Viable Product, is a technique in product development to develop a product with features enough to demonstrate the concept to the early adopters, i.e. a product with just the core features, nothing more.

The term was coined by Frank Robinson and popularized by Steven Blank and Eric Ries

The product concept is shared with the selected potential audience to gain early feedback and get a vision for the product from MVP to a full-fledged product.

MVP is a strategy to evaluate market potential of a product concept with validated inputs and minimum efforts, time and cost.

What benefits it brings in?

The product concept is evaluated at early stage with known value among potential customers
Minimum monetary and time investments
It demonstrates the concept and future benefits to reserve the early adopters
A feedback mechanism is evolved to plan the future developments

If the product concept turns to be a failure or less likely to be a success, not much harm is to be borne — only a small amount of investment was made.

But in case if it gets a green signal, you get enough time to plan for all the details and build a complete product with early feedback from market.

MVP Types

There are tons of options available for planning an MVP, I would like to mention here 5 of my favorites.

Explainer Video

It is a short video that explains what the product does and why should people buy it. Often simple, with clean animations and lasting for around 90 seconds.

These videos when designed correctly always serve the purpose and gains more visibility and a potential source of feedback and crowd funding

2. Landing Page

It is a page where all the visitors “land” on click of any ad-link or email advertisements or any other campaigns. The core objective is to quickly communicate the product value and offerings.

It can even be called as a marketing practice, but is surely an MVP as well.

You can even add an “Explainer Video” to your landing page.

Create a landing page build upon your interviews, surveys, product concept and development details
Set up Google AdWord campaign to drive traffic to the landing page
Set up Google Analytics to gain insights on page visits
Provide chat support or a contact form to improve visitor engagement, let them start a conversation and share feedback

3. Wireframes

It is a technique to present the concept visually with minimum visual elements. If the target audience is creative or tech-savvy, who can really visualize the abstract concepts, the wireframes can turn out to be very helpful with minimum cash and time. A lot of tools are available to create sketchy wireframes such as “Balsamiq”.

4. Mockups

It is a technique to present the concept visually in an enhanced manner with more efforts invested on graphical/visual aspects. Mockups turn to be an appropriate choice for the audience with little chances of understanding the concepts with just verbal explanation.

Get started with an awesome tool such as “Sketch” to build a beautiful experience.

5. Prototypes

It is a technique that fits right for the audience who want to visualize, use and get the feel of the product to understand and evaluate better. The user can use the prototypes, press a button to know what will happen next, click on links, view pictures etc.

It is often required to take care that the audiences don’t get distracted by the overlays and images and have clear focus on product functionalities and features. “Axure” is a great tool to build extensive prototypes mocked similar to the planned product.

What MVP is not?

People often skip the “Viable” aspect from MVP product. MVP is often understood as “Minimum Product”, but it is not! This misconception often makes MVP as sloppy and hideous representation of the product.

Creating a half-baked product with buggy features and partial implementation is not called a MVP, it is a messy heap of the concept and is always counter productive.

The poorly created MVPs could potentially lead to negative market feedback, even for a splendid product concept!

Why you should go for MVP’s?

Spending tremendous amount of money and efforts in designing and developing a product only to find out after a release that no one wants or needs is not something you would crave for.

At the end what we want for our product is “success” and what we want from the product is “to generate sales”. Building MVP is a great option out there.

Minimizes the time to develop the concept
Accelerates learning
Get the product early in the market and make it available to users to gain early investments or customers or words
Serve as base for the product in further development

Correctly executed and planned MVPs are win-win opportunities whether they are accepted or not accepted in the market.

They either save you from spending your hard-earned money and investing time, which could have been a waste, or
They can give you a confidence in the success of the product to get fully involved in further planning — a sustainable product complete in design and development.

You’re selling the vision and delivering the minimum feature set to visionaries, not everyone.

- Steve Blank

Author: Surbhi Mahnot, Analyst

The article was originally published by surbhimahnot on Medium.com

Enter the Business Engineer: Part 2

Mendix.com — Tue, 19 Oct 2010 19:36:00 GMT

In a previous post regarding the emergence of the Business Engineer, I discussed the Who, What and Why of this new type of human capital. At Mendix, we see them growing in numbers, most likely due to the nature of our software. If you’re going to give business analysts the ability to develop software, or developers the ability to communicate business – you’re going to see doors open and walls collapse on either side of the business-IT equation.

The BA

In order to figure out exactly where BE’s come from, so that we can harness their powers for the greater good of business agility, we’ll have to know more about their closest relative – the BA. According to The International Institute of Business Analysis, the role of a business analyst involves: “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.”

Well isn’t that something. All of those tasks and techniques are funneled down into a recommended solution and passed along to the technical wizards who turn requirements into reality. I’ve always wondered whether the less-than-technical BAs wish they could, perhaps just once, finish the job and deploy an application. Perhaps they’d hate to deal with code, I’m not sure. What I am sure of, however, is that business engineers dream about models (business-models, pervert!) and how great it would be if they could get requirements and deliver solutions, on their own.

The BE

Call it selfish; call it futuristic; you can even call it a pie in the sky. With the emergence of the business engineer, demand for agile software development, visual modeling tools and a revamped SDLC is truly explosive. Based on the definition above, the BE is not really related at all to who we now know as the business analyst. Though I mean not to offend nor aggravate business analysts or software developers, I must assume that they see the astronomies of their value propositions colliding.

So then, if the business analyst recommends a solution, it must be the business engineer who implements it. And if the business analyst plans the solution, the business engineer deploys it. I may even go as far as to say that business analysts identify the problem, where business engineers solve it. This fine, yet drastic and seemingly impossible, line – is growing in organizations everywhere.

What’s Next

As I mentioned in part one of this series of posts, the ambiguity of the business engineer is becoming more believable with every Mendix user. What was once called impossible by technologists is now championed as magic by audiences of our ‘proof’ of concepts, and we’re betting will one day be considered the norm in enterprise software development. In the meantime, collaboration between business and IT may remain segregated by occupational obstacles inherent to aging technologies and ancient practices.

The current generation of business and technology students is likely to pave the way for career paths in business engineering. Courses in business engineering will be taught by today’s business engineers, and until then, these heroes of enterprise software can only enlighten their organizations with a glimpse into the future of business agility.

Telecom Companies are ready for the Cloud

Mendix.com — Mon, 20 Sep 2010 16:26:00 GMT

Telecommunications companies are looking to cloud computing to clean up inefficient processes throughout the sales channel. The products and services in this industry change so often that these companies have become more competitive than ever, with continuously shrinking margins. Flexible front end solutions bring agility to the sales process, providing a future proof solution to front office and extended enterprise portals. As the masses continue to frenzy over new data pumping smartphones, internet connected television, and television connected internet – these organizations continue to face seemingly unparalleled challenges in business agility.

So begins the first of a series of blog posts titled “Telecom Channel Portals 2.0” in which I plan to discuss a few interesting ways that telecommunications companies will benefit in a new age of software. Software as a service is fundamentally changing the cost structure of information technology, and industries in which competition for profits is the fiercest will ultimately be the earliest adopters. The following three applications are common areas of interest for telecommunications companies looking to enter the Saas realm.

1. Marketing Portals

When products and services change as often as they do in the telecommunications industry, disseminating that knowledge throughout agent channels (partners and direct marketing/sales people) is extremely important. Marketing portals give agents and resellers access to up-to-date information from any browser. Sales in this industry are driven by intensive campaigns for which supporting marketing materials and product/service catalogs need to be readily available. There is no better way to manage and to provide this information to agents and resellers than via an online portal.

2. Quoting and Order Entry

Online portals for quoting and order entry increase direct business value for telecom providers and resellers. On either side of the equation, stakeholders get data faster and more accurately, which speeds up customer acquisition while minimizing costs. Telecom providers become more attractive to partners, and the list of benefits goes on and on. By making it quick and simple for the sales channel to give and take information from their provider, business agility is greatly improved.

3. Commission Automation

Online portals can go much further than displaying and collecting information. By including logic into an application, the functionality and time saving capabilities become endless. All too often, we see gigantic excel spreadsheets used for finance-based processes such as tracking commission payments. By automating this process, time is saved, errors are avoided, and transparency is increased. Online portals can be automated and customized for recurring commission structures based on the type of partner and product/services being sold.

These are just three ways that online portals are changing the way information is managed in the telecommunications industry. The reliance on information is so great that adopting cloud computing is almost inevitable. Keep an eye out for more “Telecom Channel Portals 2.0” posts on the Business Agility Blog.

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

Eliminating Software Documentation

Leslie — Mon, 22 Mar 2010 10:25:00 GMT

Not a suggestion for eliminating the process of documenting a software application, but rather a proposed for replacement of the documenting activity and manually produced documents with something more manageable and less likely to frighten the development team.

Initiative for this work comes from a number of discussions I have been following and also an expansion of ideas I have recently documented about best practices for software development.

1.1 Introduction

Developers nightmare – you have spent endless sleepless nights thinking about finally getting your software ready for deployment. It compiles and runs without error. It has been tested and passed user acceptance testing. It is finally ready to be released .. but, you are told that it may not be deployed until the documentation has been approved.

You have been neglecting those 200 page templates that have lying in your inbox while getting your software to compile. Now you have to spend another umpteen nights in the office writing about what it is that you have produced – yawn!

This is not a task that is going to enthuse you to do a quality job. You will probably do your best to get the documents approved asap .. anything to get your code deployed so that you can spend some quality time with family and friends.

Is this a situation you have found yourself in? I have. When I was younger, I quickly learned that this is the downside to the job of being a software developer.

Supposing though, that all you needed to do to get your software deployed, after it was already ‘working’, is to check that everything is up-to-date and consistent, post your deliverables to a ‘release’ area and organize a review meeting, with follow-up!

The following is not meant to be a complete solution, but some ideas for eliminating that boring ‘produce documentation’ task, that always seems to follow any software development effort, not only for programmers, but any member of a development team effort, including analysts, architects, testers, UI designers and any other role that produces work that needs approval.

1.2 What

Instead of identifying a document for delivery as part of a software effort, I propose to break the document into 2 components:

· the document template, and

· document contents.

Where a document has previously been identified as a deliverable, identify the document template as a deliverable. In many cases this allows for several previously deliverable documents to be replaced with a single deliverable – the template that is subsequently populated with the document contents.

This leads to 3 major activities:

· creation and management of document templates,

· production of the contents populating the template(s),

· compilation of the document from its template and contents.

1.3 How

1. Identify the stakeholders that require information that is not part of the compilable software.

2. For each stakeholder, list the information that they require in order to approve the product.

3. Work with each stakeholder to create (or select from a library) the format for a template that is an acceptable method of presenting the required information.

4. Identify dates for the delivery(s) of each template and its needed contents, and track the progress of each.

1.4 Process

For each task under How consider something along the lines of the following activities.

1.4.1 Identify Stakeholders

Stakeholders are anyone within or outside of the development team with an interest in the progress of the product. Anyone not requiring information from the product development effort, is probably not a stakeholder. Typical examples are:

· End users – who would like to see early examples of the user interface and a description of how it operates.

· Project managers – who want to be able to track the progress and effort of everything in the product repository.

· Testers – who will need to be able to access the product requirements in order to maintain test cases.

· Business owners – who will want to k now the scope of the product releases and which requirements are going to be satisfied at each release.

1.4.2 List Information

In the past when each stakeholder has been asked for their needs, they would typically turn to an existing document for reference. This document is often stripped of its current contents and has its contents replaced with information for the new product, without consideration for whether the information is ‘really’ required.

Instead, try starting with traditional document templates and work with the stakeholder to:

1. identify which sections they ‘really’ need,

2. describe the reason for this need,

3. write a description of what is documented in order to satisfy this need,

4. identify a product development timeframe for this information to be available.

Each item of information is given a location in the product repository, and duplicate information is consolidated.

Create a public interface location that always contains the latest version of each piece of information. This is the ‘release’ area.

1.4.3 Accessing Information and Publishing Documents

In many cases a stakeholder may not even require that information is presented in a traditional document form. If the stakeholder is comfortable with the repository used to contain the information, all they may need is easy access to that information.

Using a document sharing tool, such as SharePoint or a Wiki, it is relatively easy to create customized user pages that accesses only the information the stakeholder needs in a layout that makes it easy to access that information.

Alternatively, a scripted documentation tool, such as SoDA, may be used to parse a template and automatically populate it with information from the repository. Give the ability to produce the document to the stakeholder, and the development team need not be concerned with producing documents. They simply inform the stakeholders that a new version is ready for review, publish the information to the release location that the script accesses, and the stakeholder can run the script to extract the required information whenever it is convenient for them.

1.4.4 Delivery Dates And Tracking Progress

Attributes may be added to each repository element for delivery dates, assigned responsibility, progress, stakeholder(s) and a description of its contents. A reusable placeholder is created for each delivery type containing default information for each attribute.

1.5 Conclusion

As stated, the idea is not necessarily to remove documentation from the project, but to reduce the usage of the word on a development effort, and put emphasis on the ‘required’ contents and less on the document itself.

Advantages of this type of approach might be:

· The removal of unwanted/unused documentation.

· Tracking by more manageable chunks.

· Elimination of duplicate information.

· Removal of confusion over what is ‘most current’, since there is a single delivery area for every unique deliverable.

· An end to the developers nightmare of having to produce reams of documentation, after the ‘fun’ part is over.

I recognize that not all deliverable documents can necessarily be replaced in this manner. But maybe it is a start towards removing the dreaded word ‘documentation’ from a project’s deliverables list and maybe a compromise between agile proponents of minimizing documentation and those requiring documentation according to some sort of standard.

1.6 References

Links to articles that inspired this work.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=14867479&gid=1976291&trk=EML_anet_qa_ttle-0Qt79xs2RVr6JBpnsJt7dBpSBA

Best Practices

Create a product information repository that contains everything that is going to be shared amongst product stakeholders. Using this repository:

Software project methodologies

Craig Brown — Sun, 18 Jan 2009 09:26:00 GMT

Jurgen Appelo runs a blog at Noop.nl. He posted a summary on some project methods. I migrated them into a ppt for slideshare.

I hope this is intereting for you.

Software Project Methods

The Beginning of an Agile Team

Chase Petsche — Sun, 11 Jan 2009 20:37:00 GMT

I work for a rather large insurance company. We aren't the largest, but we are big enough to have our own SDLC (System Development Lifecycle) that comes packed with paper work, protocol and bureaucracy. Do not misunderstand me - these processes ensure the projects that are active are delivering on time and within budget. My last two efforts 20,000+ hours each have both come in a -2% of budget and were delivered on time. This has been largely due to the depth of documentation in terms of business requirements and tech design that had been accomplished by the time we needed to provide Execution estimates. Pretty remarkable in my opinion. So, what is the problem? Namely 14 months of project work before ANY benefit was delivered to our business partners. We changed direction with this last project - we are trying something new, and even though we've had our fair share of challenges, bumps and bruises, I'm happy with how we've progressed.

It all started when our estimates for delivery based on some scope definition and identification of high-level requirements landed us in July of 2009 - these estimates were given in August of 2008. Our project was denied the approval to continue. We were told to go back and figure out how to deliver in December 2008 or very early first quarter of 2009. Being challenged on estimates is just part of the game, but being asked to cut the effort in half and deliver the same quality of product in half the time is very difficult, if not impossible; we just don't inflate our estimates enough to trim that much fat.

Faced with this challenge, I started researching different project methodologies, different approaches, new ideas. Eventually this search landed me squarely on Agile Development. I pitched the idea to my project manager.

A couple of days later all main players of the project team were assembled. Architects, designers, developers, business analysts, business partners, project management and quality assurance were all together under one room. We reviewed the outlined objectives and in two days had an informal model of the end-state drawn up on a whiteboard. We broke the project into releases and timeboxed iterations (reqs, code, testing) to one month. Release 1 (we term 'Bare Minimum') comprised of the fewest changes needed to deliver an acceptable level of functionality to our business partners.

Release 1 is schedule to transfer later this month - not July. We will have delivered the major infrastructure needed within four iterations. The 2nd release will be within the following month - much quicker. I have a feeling that's how this project will start progressing. With the major infrastructure in place we should be able to role releases out very quickly!

We have learned many, many, many valuable lessons along the way. I'll write about those a separate time. I've been asked by others in our enterprise (different divisions than me) how I was able to persuade the executive sponsors to move to a iterative approach. I think it was a combination of a couple different factors: 1) serious time constraints, our business partners knew it and were willing to try something new; 2) willingness by a few to research, learn and introduce the team to iterative/agile principals; 3) a talented IT team who is willing, able and hungry to try new challenges and succeed in new ways.

Chase Petsche, BA III

Prince Lite has a strong focus on Requirements Management and Stakeholder Engagement.

Craig Brown — Sun, 20 Jan 2008 18:38:00 GMT

“A recently launched website aims to define a simple lightweight project delivery framework designed to combat the phenomena of PINO (Prince2 in Name Only). The new site is the brainchild of Dr. Peter Merrick and it is a synthesis of Prince2, RUP and waterfall. The main points of this new framework is it explicitly recognises the needs of all management stakeholders, it defines artifacts that are easy to understand, yet based on UML so they can be transformed into solutions, and it comes with downloads of worked examples. www.princelite.co.uk"

About Peter:
He hold a PhD from UEA in Software Engineering. I'm a UML use case expert. A paper on this subject was published last week in www.requirementsnetwork.com. This work is the subject of a paper to be delivered in Barcelona at a conference of peers in software engineering. He has worked for the Health and Safety Executive, HMRC, Great Hotel, University of Cambridge Examinations Syndicate and the European Patent Office. He currently holds a senior contract position with central government.

His motivation

"It upsets me greatly the amount of money wasted in software that never delivers. I don’t buy the excuses that are routinely bandied about for this, which normally boils down to the supplier blaming the customer for changing the requirements. This is rubbish. Suppliers are giving customers the run around. Customers have some blame to shoulder for delegating responsibility on the grounds that IT is ‘too difficult’.

Yes, databases and OO modelling is a specialist subject, but anybody can understand use case models, activity models and screen mockups. That’s all the business people need to understand."

UML takes care of the rest, because we know how to transform these ‘business oriented artifacts’ into code! The other great thing about this method is the user acceptance tests are described upfront. Progress can be measured. Success is defined. Come on customers; stop letting the tail wag the dog. Look into PrinceLite – it really is Prince in name only – and that’s a good thing."